home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000391_connolly@pixel.convex.com _Tue Nov 24 16:51:21 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  5KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA21007; Tue, 24 Nov 92 16:51:21 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA28119; Tue, 24 Nov 92 17:03:46 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA04554; Tue, 24 Nov 92 10:03:25 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA07624; Tue, 24 Nov 92 10:03:21 -0600
  10. Message-Id: <9211241603.AA07624@pixel.convex.com>
  11. To: timbl@nxoc01.cern.ch
  12. Cc: Rik Harris <rik@daneel.rdt.monash.edu.au>, www-talk@nxoc01.cern.ch
  13. Subject: Re: The <PRE> tag 
  14. Summary: Yeah, what Tim said.
  15. In-Reply-To: Your message of "Tue, 24 Nov 92 12:10:56 +0100."
  16.              <9211241110.AA03386@www3.cern.ch> 
  17. Date: Tue, 24 Nov 92 10:03:21 CST
  18. From: Dan Connolly <connolly@pixel.convex.com>
  19.  
  20.  
  21. >>  Date: Tue, 24 Nov 92 21:54:37 -1000
  22. >>  From: Rik Harris <rik@daneel.rdt.monash.edu.au>
  23. >
  24. >>  I think the <PRE> tag is a great idea, too.  The problem with not
  25. >>  having newlines significant is that it makes it difficult to do
  26. >>  indenting, etc.  One of the reasons the <PRE> tag is nice is that you
  27. >>  can take text (eg, manual entries) and not worry about formatting:
  28. >
  29. >I was sugesting that you should format the above like
  30. >
  31. >  OPTIONS<p>
  32. ><p>
  33. >    -b   this option performs the blah command.  And if this line is<p>
  34. >         reasonably long, I can demonstrate what I'm talking about.<p>
  35. ><p>  
  36. >
  37. >    -f   this option performs the foo command.  Another annoying prob-<p>
  38. >         lem is hyphenation.<p>
  39. >
  40. >That is, you explicitly put in the line end, but all white space is significan
  41. t  
  42. >on the line.. It means that lines like
  43. >
  44. >    See also csh, cc, blah, fred and junk.
  45. >
  46. >which would have to be a SINGLE LINE
  47. >See also  <a name=csh href=csh.html>csh</a>, <a name=cc href=cc.html>cc</a>, <a  
  48. >name=blah2 href=http://sdf.adf.uasdf.edu/fred/doc/junk/blah.html>blah</a>, <a 
  49. >name=fred href=fred.html>fred</a> and <a name=junk href=junk.html>csh</a>.
  50. >
  51. >instead could out as for example
  52. >
  53. >See also  
  54. >
  55. > <a name=csh href=csh.html>csh</a>, 
  56. >
  57. > <a name=cc href=cc.html>cc</a>, 
  58. >
  59. > <a name=blah2 href=http://sdf.adf.uasdf.edu/fred/doc/junk/blah.html>blah</a>,
  60. > <a name=fred href=fred.html>fred</a> and <a name=junk href=junk.html>csh</a>.
  61. ><p>
  62. >
  63. >which is mailable.  If you look atthe NJIT manual pages HTML, there is a  
  64. >mixture of significant line feeds and explicit <p> elements for blank lines:
  65. >
  66. >  OPTIONS
  67. ><p>
  68. >    -b   this option performs the blah command.  And if this line is
  69. >         reasonably long, I can demonstrate what I'm talking about.
  70. ><p>  
  71. >
  72. >    -f   this option performs the foo command.  Another annoying prob-
  73. >         lem is hyphenation.
  74. ><p>
  75. >
  76. >I propose we settle for one or the other.  I wonder whether there is
  77. >anything in SGML to suggest which.
  78.  
  79. In fact, there is. Well, not actally in SGML, but in the "application
  80. conventions" that I have used to map SGML onto WWW.
  81.  
  82. All elements in HTML have either mixed content, RCDATA, or CDATA.
  83. Mixed content is a mixture of <tags>, &entity; references,
  84. and #PCDATA. RCDATA is just &entities; and data. CDATA is just data.
  85.  
  86. [SGML actually has a couple other content modes: ANY and
  87. element content, but I didn't use those.]
  88.  
  89. CDATA is only used for the TITLE. RCDATA is used for XMP and LISTING
  90. (entity references _are_ recognized in RCDATA sections, so you
  91. can inlclude the _full_ end tag like this: </XMP>. But the
  92. string </ followed by a letter _ends_ the section, whether the
  93. letter starts the XMP tag or not.)
  94.  
  95. The convention is that in PCDATA sections, newlines serve only
  96. to delimit words, whereas in RCDATA, newlines are significant.
  97.  
  98. We can't use RCDATA for the PRE or FIXED tag, cuz the <a> tag
  99. won't be recognized in RCDATA. So I'd suggest you ignore
  100. newlines inside the PRE element, and use <p> to delimit lines.
  101. And since we're not using the exact semantics of PRE, I like
  102. the idea of using the name FIXED in stead.  In SGML:
  103.  
  104. <!ELEMENT FIXED - - (#PCDATA|A|P)*>
  105.  
  106. The fact that the MidasWWW browser can support the semantics
  107. of PRE is due to its non-standard parsing, where it treats
  108. illegal tags as data, rather than ignoring them. SGML says
  109. they'r not data, whatever they are, and the HTML doc in
  110. the web says to ignore them.
  111.  
  112. I'm integrating my low-level SGML reading routines into
  113. MidasWWW now, and with the author's consent, the non-standard
  114. behaviour will soon go away. [The MidasWWW 1.0 browser doesn't
  115. do < or & either -- that too will change.]
  116.  
  117. I've got it running, but there are a couple integration bugs I haven't
  118. yet tracked down.
  119.  
  120. I've also got something of a validation suite for HTML, so that
  121. implementors can easily see if they've gotten it right. And the
  122. suite goes from easy to hard, so they can see how much of it
  123. they got right, and if they don't want to fix it, they can at least
  124. document how much it's broken.
  125.  
  126. Dan
  127.